Allow lazier configuration of jdks#19
Conversation
Generate changelog in
|
| import org.gradle.api.provider.Provider; | ||
| import org.gradle.api.provider.ProviderFactory; | ||
|
|
||
| final class DelayedConfigurableMap<K, V> { |
There was a problem hiding this comment.
I tried to use some of the built in NamedDomainObjectCollection/MapProperty but they really did not seem to do exactly what I wanted - so I build my own thing here.
…tir/gradle-jdks into callumr/allow-lazier-configuration
| final class DelayedConfigurableMap<K, V> { | ||
| private final ProviderFactory providerFactory; | ||
| private final Supplier<V> valueFactory; | ||
| private final List<Provider<Map<K, Action<V>>>> configurations = new ArrayList<>(); |
There was a problem hiding this comment.
>>>> looks a lot like a merge conflict!
There was a problem hiding this comment.
This is how you tell it's good code
| import org.gradle.api.provider.Provider; | ||
| import org.gradle.api.provider.ProviderFactory; | ||
|
|
||
| final class DelayedConfigurableMap<K, V> { |
There was a problem hiding this comment.
What would it look like to abandon the map concept entirely, in favor of something shaped more like a function? I suspect this isn't the only place the map property may bite us
There was a problem hiding this comment.
I agree we should probably do that, started it here: palantir/gradle-baseline#2263
There was a problem hiding this comment.
I updated this PR to show what it would look like.
|
Released 0.4.0 |
4 participants
Before this PR
When configuring an internal Gradle plugin to configure this plugin I ran into a problem - I couldn't work out which JDKs I had without doing an expensive network task - basically what @carterkozak warning me about in the baseline code.
After this PR
==COMMIT_MSG==
Allow lazy configuration of JDKs
==COMMIT_MSG==
Extra methods allow me to provide all the jdk configuration lazily when it is requested.
Possible downsides?